Distributed network applications often require an efficient and reliable real-time data communication system. Applications need to send and receive messages to other applications running on separate computers linked by a local area network. Such a messaging system should be able to handle a high volume of messages.
Various systems and techniques have been previously developed for data communication for distributed network applications. One such previously developed system is a “heavyweight” peer-to-peer messaging system. The heavyweight peer-to-peer messaging system employs two types of components. The first type of component is a messaging client library that is linked into every custom application that needs to send or receive messages. The second type of component is a messaging daemon that handles the network broadcasting of the messages. This messaging daemon needs to be running on every machine that is sending or receiving messages. Such daemon is a process that runs in the background (without a visible user interface) and performs a specified operation at predefined times or in response to certain events. In general, daemons are usually spawned automatically by a system and may either live forever or be regenerated at intervals.
Another previously developed messaging system employs a client-server architecture. Such a client-server system consists of multiple messaging clients communicating with one or more stand-alone messaging servers. The clients have messaging libraries linked into custom applications like in the peer-to-peer system described above. Each messaging server has a daemon resident thereon.
Both the heavyweight peer-to-peer and client-server messaging architectures suffer from numerous problems. For example, in the heavyweight peer-to-peer model, inter-process communication (IPC) calls between the messaging library and the messaging daemon are required for messaging, thereby comprising performance. This is in addition to the required network communication that is needed to broadcast the messages from a sending messaging daemon to one or more receiving messaging daemons. In the client-server model, performance is compromised because messages need to be sent to a messaging server before being broadcast to the receiving client machines.
In the heavyweight peer-to-peer model, reliability is an issued because the messaging daemon could be a potential failure point on every machine that needs to send and receive messages. If the messaging daemon fails or is accidentally stopped, none of the applications running on the machine will be able to send or receive messages. In the client-server model, the use of a single messaging server presents a single point of failure. Using one or more additional messaging servers alleviates this reliability issue, but increases overall costs.
In the heavyweight peer-to-peer model, a messaging daemon must be configured and initiated for each machine that is sending and receiving messages, thereby complicating the task of system configuration. In the client-server model, system configuration is complicated by the need to configure and maintain the messaging server machines and the daemons resident thereon.
In addition, many previously developed messaging solutions use the Transmission Control Protocol (TCP). TCP provides a unicast point-to-point transmission mechanism with message acknowledgement for reliable messaging. TCP is suitable when there is one sender and one recipient for any given message. However, to send a message from one machine to many others using the unicast mechanism is bandwidth intensive. For example, to send a message to five recipients with the unicast mechanism of TCP requires five separate transmissions of the same data.